A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on volumes as a hierarchical structure of data containers, such as files and logical units (LUs). A known type of file system is a write-anywhere file system that does not overwrite data on disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL®) file system available from NetApp, Inc. Sunnyvale, Calif.
The storage system may be further configured to allow many servers to access data containers stored on the storage system. In this model, the server may execute an application, such as a database application, that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each server may request the data services of the storage system by issuing access requests (read/write requests) as file-based and block-based protocol messages (in the form of packets) to the system over the network.
A plurality of storage systems may be interconnected to provide a storage system architecture configured to service many server. In some embodiments, the storage system architecture provides one or more aggregates, each aggregate comprising a set of one or more storage devices (e.g., disks). Each aggregate may store one or more storage objects, such as and one or more volumes. The aggregates may be distributed across a plurality of storage systems interconnected as a cluster. The storage objects (e.g., volumes) may be configured to store content of data containers, such as files and logical units, served by the cluster in response to multi-protocol data access requests issued by servers.
Each storage system (node) of the cluster may include (i) a storage server (referred to as a “D-blade”) adapted to service a particular aggregate or volume and (ii) a multi-protocol engine (referred to as an “N-blade”) adapted to redirect the data access requests to any storage server of the cluster. In the illustrative embodiment, the storage server of each storage system is embodied as a disk element (D-blade) and the multi-protocol engine is embodied as a network element (N-blade). The N-blade receives a multi-protocol data access request from a client, converts that access request into a cluster fabric (CF) message and redirects the message to an appropriate D-blade of the cluster.
The storage systems of the cluster may be configured to communicate with one another to act collectively to increase performance or to offset any single storage system failure within the cluster. The cluster provides data service to servers by providing access to a shared storage (comprising a set of storage devices). Typically, servers will connect with a storage system of the cluster for data-access sessions with the storage system. During a data-access session with a storage system, a server may submit access requests (read/write requests) that are received and performed by the storage system. Each server typically executes numerous applications requiring the data services of the cluster.
A current trend in storage system environments is to virtualize application and storage resources in the cluster. A virtual server environment may typically include multiple physical servers accessing the storage system having multiple storage devices for storing client data. Each server may include multiple virtual machines (VMs) that reside and execute on the server. Each VM (sometimes referred to as a virtual application or virtual server) may comprise a separate encapsulation or instance of a separate operating system and one or more applications that execute on the server. As such, each VM on a server may have its own operating system and set of applications and function as a self-contained package on the server and multiple operating systems may execute simultaneously on the server.
Each VM on a server may be configured to share the hardware resources of the server. Each server may include a VM manager module/engine (e.g., VMware™ ESX, Microsoft™ Hyper-V, Citrix XenServer™, etc. that executes on the server to produce and manage the VMs. The VM manager module/engine may also virtualize the hardware and/or software resources of the servers for use by the VMs. The operating system of each VM may utilize and communicate with the resources of the server via the VM manager engine. The virtual server environment may also include a plurality of clients connected with each server for accessing client data stored on the storage system. Each client may connect and interface/interact with a particular VM of a server to access client data of the storage system. From the viewpoint of a client, the VM may comprise a virtual server that appears and behaves as an actual physical server or behaves as an actual desktop machine. For example, a single server may by “virtualized” into 1, 2, 4, 8, or more virtual servers or virtual desktops, each running their own operating systems, and each able to support one or more applications.
A storage system may be configured to allow servers to access its data, for example, to read or write data to the storage system. A server may execute an application that “connects” to the storage system over a computer network such as a shared local area network (LAN), a wide area network (WAN), or a virtual private network (VPN) implemented over a public network such as the Internet. The application may send an access request (read or write request) to the storage system for accessing particular data stored on the storage system. Each server may also include multiple VMs, each VM being used by and connected with a client through a computer network. Each VM may also execute an application for sending read/write requests (received from the connected client) for accessing data on the storage system. The VM applications executing on the server may service the connected clients by receiving the client access requests and submitting the access requests to the storage system for execution.
There are several advantages in implementing VMs on a server. Having multiple VMs on a single server enables multiple clients to use multiple different operating systems executing simultaneously on the single server. Also, multiple VMs executing their own applications may be logically separated and isolated within a server to avoid conflicts or interference between the applications of the different VMs. As each VM is separated and isolated from other VMs, a security issue or application crash in one VM does not affect the other VMs on the same server. Also, VMs can rapidly and seamlessly be shifted from one physical server to any other server, and optimally utilize the resources without affecting the applications. Such a virtualization of the servers, and/or virtualization of the storage network environment, allows for efficiency and performance gains to be realized.
As discussed above, the VM manager module/engine of a physical server may virtualize the hardware and/or software resources for use by the VMs. For each physical server these resources may include storage resources/objects (e.g., volumes, logical units, etc.) distributed on one or more storage systems. Each storage system may allocate its storage objects to one or more physical servers, each allocated storage object being “mounted” (i.e., made available) to a particular physical server. For example, a storage system may allocate one or more logical units (LUs) to a physical server, each LU being mounted and made available to the physical server. Each physical server may have one or more LUs available for use from one or more storage systems. A mounted storage object may appear to the server as a direct-attached physical storage device, such as a direct-attached Small Computer System Interface (SCSI) or Serial ATA (SATA) disk device.
Some or all storage resources/objects (e.g., LUs) that are made available to a physical server may be virtualized by the VM manager module for use by the VMs. The VM manager module may virtualize the storage objects by producing virtual storage components for use by the VMs and virtual storage information that describes these virtual storage components. For example, a virtual storage component may comprise a virtual hard disk (VHD) or virtual machine disk (VMDK) allocated to a VM. For each VM, the VM manager module may allocate one or more virtual storage components for use by the VM for accessing and storing data. The virtual storage information may be used by a VM to locate and access its virtual storage component(s).
To a VM, each virtual storage component may appear as a directly attached physical storage device (e.g., a drive or disk) that is directly accessed by the VM. But in fact, each virtual storage component is supported by an underlying corresponding storage resource/object residing somewhere on one of the storage systems. As used herein, an “underlying” storage object corresponding to a virtual storage component comprises the storage object on the storage system that stores the actual data for the virtual storage component. As such, data accesses (e.g., read/write accesses) to and from the virtual storage component by the VM ultimately comprises data accesses to and from the underlying storage object corresponding to the virtual storage component.
Another current trend in storage system environments is to provide policy management over storage objects stored on the storage systems. Policy management may provide services such as maintenance, monitoring, backup, etc. of the storage objects. Current policy management programs, however, do not provide policy management at a higher level than the storage objects on the storage systems and do not provide policy management for any virtual entities (such as virtual applications and virtual storage components). As such, there is a need for a system and method for providing a more flexible and efficient higher level policy management for non-virtual as well as virtual applications and storage resources.